The present invention relates to the field of data processing, and more particularly where a group of server data processing systems are being workload managed with respect to work requests originating from a client data processing system.
Client/server computing has become more and more important over the past few years in the information technology world. This type of distributed computing allows one machine to delegate some of its work to another machine that might be, for example, better suited to perform that work. For example, the server could be a high-powered computer running a database program managing the storage of a vast amount of data, while the client is simply a desktop personal computer (PC) which requests information from the database to use in one of its local programs.
In client/server data processing, a client directs a unit of work request to a particular server, which the client knows to have the capability of carrying out the unit of work on behalf of the client. Of course, a server can also function as a client, so inter-server requests are also common. In situations where a particular server is expected to have a large number of requests directed thereto, and also in situations where it is imperative that the server be always operational, it is very common to provide a group of servers, each of which is capable of carrying out certain units of work. For a particular unit of work being directed to the server group, a workload management unit makes a decision as to which particular member of the server group this particular unit of work request should be assigned. For example, the least busiest server in the group is chosen, or if one server in the group is experiencing a malfunction, another server in the group will be chosen to handle the request.
In the following description, the originator of a unit of work request that is attempting to access the server group will be referred to as an xe2x80x9centityxe2x80x9d. In one case, an entity could be a client. In another case (which is the more common case) an entity is a transaction, and thus in this case the type of data processing that is taking place is called transaction processing.
If an entity that is accessing a server group accesses the same server group again at a later time, it is highly advantageous for this later access to return to the same server in the group that was used during the previous access. This ensures that data integrity is maintained and also improves performance. This is known in the art as xe2x80x9caffinityxe2x80x9d (i.e., all work on behalf of a particular entity is processed on the same server for a particular server group).
One prior art way to establish such affinity (taking the common example of where the entity is a transaction) is to place a mapping list of transactions to servers within each server group. When a request arrives at the server group, the request is checked to determine if it is part of a transaction, and if it is, the mapping list is checked by the server group workload manager to determine if the transaction is on the mapping list and, if it is on the list, to which server in the group the mapping list maps the transaction. The workload manager then sends the request to this particular server, thus maintaining transaction affinity, because each time a request comes in to the server group that is part of a particular transaction, the same server in the group will be chosen. This prior art technique has been implemented in IBM""s Component Broker 390 (CB/390)(xe2x80x9cComponent Broker 390xe2x80x9d and xe2x80x9cCB/390xe2x80x9d are trademarks of IBM Corp.) software product. It has also been implemented in IBM""s CICSPlexSM (xe2x80x9cCICSPlexSMxe2x80x9d is a trademark of IBM Corp.) software product.
This prior art technique suffers from disadvantages. Particularly, as transactions are completed, there is no need to maintain mappings for such completed transactions in the mapping tables, otherwise, the tables will grow too large with information that is no longer useful. Thus, there is a need in the prior art to constantly maintain (i.e., xe2x80x9cclean upxe2x80x9d) the mapping tables, thus requiring extra maintenance code within each server group.
According to one aspect, the present invention provides in a client/server data processing system where a client sends a work request to a server which includes a group of workload managed server data processing processes each of which is capable of performing the work request, a server data processing apparatus running a server data processing process, the apparatus has: a data storage unit storing mapping data which maps a particular server data processing process to each of a plurality of groups of workload managed server data processing processes; a means for receiving from a client a request for the identity of the mapped server data processing process corresponding to a particular group of workload managed server data processing processes, the particular group being specified in the request; a means for accessing the data storage unit to determine, for the particular group specified in the received request, the identity of the mapped server data processing process; and a means for returning the identity of the mapped server data processing process to the client; wherein the request received from the client is associated with an entity whose lifetime is coupled to the lifetime of the server data processing process.
According to a second aspect, the present invention provides a method for carrying out the functionality described above with respect to the first aspect.
According to a third aspect, the present invention provides a computer program product, stored on a computer readable storage medium, for, when run on a computer, carrying out the functionality described above with respect to the first aspect.
Therefore, the present invention maintains the mapping list of server group to server for a particular requesting entity, in a central location, rather than at each server group. When the requesting entity wishes to access a server group, the requesting entity first accesses this central location to determine, for a particular server group, which server in the server group should be used. This greatly reduces the amount of maintenance that must be carried out as entities become no longer relevant (e.g., as transactions complete).
The prior art has avoided using such centralized mapping because of the fact that the centralized mapping would become a single point of failure (i.e., if the centralized mapping goes down then the entire system that relies on it will be out of operation). However, a single point of failure is not considered a problem in the context of the present invention because the centralized mapping is maintained within a single process whose lifetime (i.e., lifecycle) is coupled to the lifecycle of the requesting entity.
For example, where the requesting entity is a transaction, the central location for keeping-the mapping data is stored at the transaction""s root (i.e., the top of the transaction tree), thus, when the transaction completes the transaction tree is automatically deleted. Placing the mapping list at the transaction""s root also has the advantage of making it very easy for a requesting process within the transaction to find the central location because the requesting process need only trace back through the transaction tree until the root is reached. That is, the existing transaction tree structure can be used as the path from requesting process to mapping list central location.